home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / iso / 10021_23.asc < prev    next >
Text File  |  1992-12-23  |  15KB  |  267 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20. Section Three - Configurations
  21. 11.      Overview
  22. This section specifies  how  one  can  configure  the  MHS  to  satisfy  any  of  a  variety
  23. of functional, physical, and organizational requirements.
  24. This section covers the following topics:
  25. a)   Functional configurations
  26. b)   Physical configurations
  27. c)   Organizational configurations
  28. d)   The Global MHS
  29. 12.      Functional Configurations
  30. This  clause  specifies  the  possible   functional   configurations   of   the   MHS.   The
  31. variety of such configurations results from  the  presence  or  absence  of  the  Directory,
  32. and from whether a direct user employs an MS.
  33. 12.1     Regarding the Directory
  34. With respect to the Directory,  the  MHS  can  be  configured  for  a  particular  user,  or
  35. a  collection  of  users  (e.g.,  see  clause  14.1),  in  either  of  two  ways:  with   or
  36. without the Directory. A user without access to the  Directory  may  lack  the  capabilities
  37. described in section five.
  38. Note    A  partially,  rather  than  fully  interconnected  Directory  may  exist   for   an
  39. interim period  during  which  the  (global)  Directory  made  possible  by  Recommendations
  40. for Directories is under construction.
  41. 12.2     Regarding the Message Store
  42. With respect to the MS,  the  MHS  can  be  configured  for  a  particular  direct  user  in
  43. either of two ways: with or without an MS.  A  user  without  access  to  an  MS  lacks  the
  44. capabilities of  Message  Storage.  A  user  in  such  circumstances  depends  upon  his  UA
  45. for the storage of information objects, a capability that is a local matter.
  46. The  two  functional  configurations  identified  above  are  depicted  in  Figure   7/X.402
  47. which  also  illustrates  one  possible  configuration  of  the  MTS,  and  its  linkage  to
  48. another communication system via an AU. In the  figure,  user  2  is  equipped  with  an  MS
  49. while user 1 is not.
  50. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
  51. | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
  52. | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  53. Figure .F.:7/X.402 Functional Configurations Regarding the MS
  54. Note   While the  users  depicted  in  the  figure  are  people,  the  figure  applies  with
  55. equal force and validity to users of other kinds.
  56. 13.      Physical Configurations
  57. This  clause  specifies  the  possible  physical  configurations  of  the  MHS,  i.e.,   how
  58. the MHS  can  be  realized  as  a  set  of  interconnected  computer  systems.  Because  the
  59. number of  configurations  is  unbounded,  the  clause  describes  the  kinds  of  messaging
  60. systems from which the MHS is assembled,  and  identifies  a  few  important  representative
  61. configurations.
  62. 13.1     Messaging Systems
  63. The  building  blocks  used  in  the  physical  construction   of   the   MHS   are   called
  64. messaging systems. A  .I.gl:messaging  system;  is  a  computer  system  (possibly  but  not
  65. necessarily an open system) that contains, or realizes, one of more functional objects.
  66. Messaging systems are of the types depicted in Figure 8/X.402.
  67. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
  68. | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
  69. | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  70. Figure .F.:8/X.402 Messaging System Types
  71. The  types  of  messaging  system,  depicted  in  the  figure,  are  listed  in  the   first
  72. column of Table 8/X.402. For each  type  listed,  the  second  column  indicates  the  kinds
  73. of  functional  object--UAs,  MSs,  MTAs,  and  AUs--that  may  be   present   in   such   a
  74. messaging system, whether their presence is mandatory or optional, and whether just  one  or
  75. possibly several of them may be present in the messaging system.
  76. The  table  is  divided  into  two  sections.  Messaging  systems  of  the  types   in   the
  77. first section are dedicated to single users, those of the  types  in  the  second  can  (but
  78.  
  79.  
  80.  
  81.  
  82.  
  83.  
  84. need not) serve multiple users.
  85. Table .T.:8/X.402 Messaging Systems
  86. +-----------+--------------------+  |            |  Functional   Objects   |   |   Messaging
  87. +--------------------+ |  System     |   UA    MS   MTA   AU   |  +-----------+-------------
  88. --------+ | A/SYS     |  1    -    -     -   |  |  S/SYS      |   -     1     -     -   |  |
  89. AS/SYS    |  1    1     -     -   |  +-----------+--------------------+  |  T/SYS      |   -
  90.   -    1   [M] |  |  AT/SYS     |   M     -     1    [M]  |  |  ST/SYS     |   -     M     1
  91. [M]  |  |  AST/SYS    |   M     M     1    [M]  |   +-----------+--------------------+    +-
  92. Legend -------------------+ | M multip e   [...]  optional  |  +----------------------------
  93. -+
  94. The  messaging  system  types,  summarized  in  the  table,  are  individually  defined  and
  95. described in the clauses below.
  96. Note    The  following  major  principles  governed  the  admission  of   messaging   system
  97. types:
  98. a)   An AU and the  MTA  with  which  it  interacts  are  typically  co-located  because  no
  99. protocol to govern their interaction is standardized.
  100. b)    An  MTA  is  typically  co-located  with  multiple  UAs  or  MSs   because,   of   the
  101. standardized  protocols,  only  that  for  transfer  simultaneously  conveys  a  message  to
  102. multiple recipients. The serial delivery of a message to multiple  recipients  served  by  a
  103. messaging system, which the delivery protocol would require, would be inefficient.
  104. c)   No purpose is served  by  co-locating  several  MTAs  in  a  messaging  system  because
  105. a single MTA serves multiple users,  and  the  purpose  of  an  MTA  is  to  convey  objects
  106. between, not within  such  systems.  (This  is  not  intended  to  exclude  the  possibility
  107. of several MTA-related processes co-existing within a single computer system.)
  108. d)   The co-location  of  an  AU  with  an  MTA  does  not  affect  that  system's  behavior
  109. with  respect  to  the  rest  of  the  MHS.  A  single  messaging  system  type,  therefore,
  110. encompasses the AU's presence and absence.
  111. 13.1.1   Access Systems
  112. An .I.gl:access  system;  (.I.ab:A/SYS;)  contains  one  UA  and  neither  an  MS,  an  MTA,
  113. nor an AU.
  114. An A/SYS is dedicated to a single user.
  115. 13.1.2   Storage Systems
  116. A  .I.gl:storage  system;  (.I.ab:S/SYS;)  contains  one  MS  and  neither  a  UA,  an  MTA,
  117. nor an AU.
  118. An S/SYS is dedicated to a single user.
  119. 13.1.3   Access and Storage Systems
  120. An  .I.gl:access  and  storage  system;  (.I.ab:AS/SYS;)  contains  one  UA,  one  MS,   and
  121. neither an MTA nor an AU.
  122. An AS/SYS is dedicated to a single user.
  123. 13.1.4   Transfer Systems
  124. A  .I.gl:transfer  system;  (.I.ab:T/SYS;)  contains  one  MTA;  optionally,  one  or   more
  125. AUs; and neither a UA nor an MS.
  126. A T/SYS can serve multiple users.
  127. 13.1.5   Access and Transfer Systems
  128. An .I.gl:access  and  transfer  system;  (.I.ab:AT/SYS;)  contains  one  or  more  UAs;  one
  129. MTA; optionally, one or more AUs; and no MS.
  130. An AT/SYS can serve multiple users.
  131. 13.1.6   Storage and Transfer Systems
  132. A .I.gl:storage  and  transfer  system;  (.I.ab:ST/SYS;)  contains  one  or  more  MSs;  one
  133. MTA; optionally, one or more AUs; and no UA.
  134. An ST/SYS can serve multiple users.
  135. 13.1.7   Access, Storage, and Transfer Systems
  136. An  .I.gl:access,  storage,  and  transfer  system;   (.I.ab:AST/SYS;)   contains   one   or
  137. more UAs; one or more MSs; one MTA; and optionally, one or more AUs.
  138. An AST/SYS can serve multiple users.
  139. 13.2     Representative Configurations
  140. Messaging  systems  can  be  combined  in  various  ways  to  form  the  MHS.  The  possible
  141. physical  configurations  are  unbounded  in  number  and   thus   cannot   be   enumerated.
  142. Several important  representative  configurations,  however,  are  described  below  and  in
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154. Figure 9/X.402.
  155. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
  156. | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
  157. | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  158. Figure .F.:9/X.402 Representative Physical Configurations
  159. Notes
  160. 1.  While  the  users  depicted  in  the  figure  are  people,  the  figure   applies   with
  161. equal force and validity to users of other kinds.
  162. 2.  Besides  the  physical  configurations  that   result   from   the   "pure"   approaches
  163. below, many "hybrid" configurations can be constructed.
  164. 13.2.1   Fully Centralized
  165. The MHS may be  fully  centralized  (panel  a  of  the  figure).  This  design  is  realized
  166. by a  single  AST/SYS  which  contains  functional  objects  of  all  kinds  and  which  can
  167. serve multiple users.
  168. 13.2.2   Centralized Message Transfer and Storage
  169. The  MHS  may  provide  both  Message  Transfer  and  Message  Storage  centrally  but  user
  170. access distributedly (panel  b  of  the  figure).  This  design  is  realized  by  a  single
  171. ST/SYS and, for each user, an A/SYS.
  172. 13.2.3   Centralized Message Transfer
  173. The MHS may  provide  Message  Transfer  centrally  but  Message  Storage  and  user  access
  174. distributedly (panel  c  of  the  figure).  This  design  is  realized  by  a  single  T/SYS
  175. and, for each user, either an AS/SYS alone or an S/SYS and an associated A/SYS.
  176. 13.2.4   Fully Distributed
  177. The  MHS  may  provide  even  Message  Transfer  distributedly  (panel  d  of  the  figure).
  178. This design involves multiple ST-SYNs or T-SYNs.
  179. 14.      Organizational Configurations
  180. This  clause  specifies  the  possible  organizational  configurations  of  the  MHS,  i.e.,
  181. how  the  MHS  can  be  realized  as  interconnected  but  independently  managed  sets   of
  182. messaging  systems  (which  are  themselves   interconnected).   Because   the   number   of
  183. configurations is unbounded, the clause describes  the  kinds  of  management  domains  from
  184. which  the   MHS   is   assembled,   and   identifies   a   few   important   representative
  185. configurations.
  186. 14.1     Management Domains
  187. The primary building  blocks  used  in  the  organizational  construction  of  the  MHS  are
  188. called    management    domains.    A    .I.gl:management    domain;     (.I.ab:MD;)     (or
  189. .I.gl:domain;) is a set of messaging systems--at least one of which contains, or realizes, an 
  190. MTA--that is managed by a single organization.
  191. The  above  does  not  preclude  an  organization  from  managing   a   set   of   messaging
  192. systems (e.g., a single A/SYS) that does not qualify as an MD for lack of  an  MTA.  Such  a
  193. collection  of  messaging  systems,  a  secondary  building   block   used   in   the   MHS'
  194. construction, "attaches" to an MD.
  195. MDs  are  of  several  types  which  are  individually  defined   and   described   in   the
  196. clauses below.
  197. 14.1.1   Administration Management Domains
  198. An   .I.gl:administration   management    domain;    (.I.ab:ADMD;)    comprises    messaging
  199. systems managed by an Administration.  The  major  technical  distinction  between  an  ADMD
  200. and a PRMD is that the former is positioned  above  the  latter  in  the  MHS'  hierarchical
  201. addressing (see clause 18) and routing (see clause 19) regimes.
  202. Note   An ADMD provides Message Handling to the public.
  203. 14.1.2   Private Management Domains
  204. A   .I.gl:private   management   domain;   (.I.ab:PRMD;)   comprises    messaging    systems
  205. managed by an organization other than an Administration.  The  major  technical  distinction
  206. between a PRMD and an ADMD is that  the  former  is  positioned  below  the  latter  in  the
  207. MHS' hierarchical addressing (see clause 18) and routing (see clause 19) regimes.
  208. Note   A  PRMD  provides  Message  Handling,  e.g.,  to  the  employees  of  a  company,  or
  209. to those employees at a particular company site.
  210. 14.2     Representative Configurations
  211. MDs can  be  combined  in  various  ways  to  form  the  MHS.  The  possible  organizational
  212. configurations  are  unbounded  in  number  and   thus   cannot   be   enumerated.   Several
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219. important  representative  configurations,  however,  are  described  below  and  in  Figure
  220. 10/X.402.
  221. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
  222. | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
  223. | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  224. Figure .F.:10/X.402 Representative Organizational Configurations
  225. Note    Besides  the   organizational   configurations   that   result   from   the   "pure"
  226. approaches below, many "hybrid" configurations can be constructed.
  227. 14.2.1   Fully Centralized
  228. The entire  MHS  may  be  managed  by  one  organization  (panel  a  of  the  figure).  This
  229. design is realized by a single MD.
  230. 14.2.2   Directly Connected
  231. The  MHS  may  be  managed  by  several  organizations,  the  messaging  systems   of   each
  232. connected to the messaging systems of all of the others  (panel  b  of  the  figure).   This
  233. design is realized by multiple MDs interconnected pair-wise.
  234. 14.2.3   Indirectly Connected
  235. The  MHS  may  be  managed  by  several  organizations,  the  messaging   systems   of   one
  236. serving as intermediary between the  messaging  systems  of  the  others  (panel  c  of  the
  237. figure). This design is realized by multiple MDs one  of  which  is  interconnected  to  all
  238. of the others.
  239. 15.      The Global MHS
  240. A  major  purpose  of  this  Recommendation  and  others  in  the  set  is  to  enable   the
  241. construction of the .I.gl:Global MHS;, an MHS providing both intra- and inter-organizational, and both intra- and international Message Handling world-wide.
  242. The  Global  MHS   almost   certainly   encompasses   the   full   variety   of   functional
  243. configurations specified in clause 12.
  244. The   physical   configuration   of   the   Global   MHS   is   a   hybrid   of   the   pure
  245. configurations specified in clause 13, extremely complex and highly distributed physically.
  246. The  organizational  configuration  of  the  Global  MHS   is   a   hybrid   of   the   pure
  247. configurations  specified  in  clause  14,  extremely   complex   and   highly   distributed
  248. organizationally.
  249.       Figure  11/X.402  gives  an  example  of  possible  interconnections.  It   does   not
  250. attempt to  identify  all  possible  configurations.  As  depicted,  ADMDs  play  a  central
  251. role  in  the  Global  MHS.  By  interconnecting  to  one  another   internationally,   they
  252. provide   an   international   Message   Transfer   backbone.   Depending   upon    national
  253. regulations, by interconnecting to one another domestically, they may also provide  domestic
  254. backbones joined  to  the  international  backbone.  ADMDs  also  serve  as  primary  naming
  255. authorities in the assignment of O/R addresses to users and DLs.
  256. PRMDs  play  a  peripheral  role  in  the  Global  MHS,  being   connected   to   the   ADMD
  257. backbone which serves as an intermediary between them.
  258. +----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 |  |  08  |  |  09  |  |  10  |  |  11
  259. | | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20  |  |  21  |  |  22  |  |  23
  260. | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
  261. Figure .F.:11/X.402 The Global MHS
  262.  
  263.  
  264.  
  265.  
  266.  
  267.